IRIX Development Foundation for IRIX 6.4

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Development Foundation for IRIX 6.4 / SGI IRIX 6.4 Development Foundation.iso / docs6.4 / relnotes / c++_dev / ch1.z / ch1

Wrap

Text File | 1997-09-11 | 73KB | 2,181 lines

- 1 - 7.2 C++ Release Notes DDDDooooccccuuuummmmeeeennnntttt NNNNuuuummmmbbbbeeeerrrr 000000007777....2222666600006666----000011110000 - 2 - 1. _I_n_t_r_o_d_u_c_t_i_o_n The Silicon Graphics C++ Compiler is an environment for compiling programs written in the C++ programming language. This environment allows access to standard IRIX features and to the Graphics Library. The MIPSpro 7.2 release of the compiler is a native C++ compiler based on a frontend from the Edison Design Group. The latest set of compilers, invoked when -n32, -64, -mips3 or -mips4 is specified on the command-line, is based on the n32/64 ABI, introduced with the 6.2 compilers. For backwards compatibility, the older ucode-based compilers are also bundled with this release; these can be invoked with -32, -mips1, or -mips2. Note that the n32/64 compilers have been available for over a year and we strongly recommend that you use these. Note also that these n32/64 compilers closely reflect the C++ draft in terms of the language accepted and also provide the features and performance enhancements described in detail subsequently in these release notes. There will be no further development work on the ucode-based compilers. The n32 and 64-bit versions are based on release 2.34 of the Edison frontend. The 32-bit version is based on release 2.29 of the Edison frontend. The old frontend based on release 3.0.1 of the USL C++ Translator (_c_f_r_o_n_t), is also available by specifying the options -_3_2 -_u_s_e__c_f_r_o_n_t. Note that the use of this option is being deprecated and the _c_f_r_o_n_t compiler will no longer be supported in future releases. 1.1 _I_n_s_t_a_l_l_a_t_i_o_n__I_n_f_o_r_m_a_t_i_o_n This section lists supplemental information to the _I_R_I_S _S_o_f_t_w_a_r_e _I_n_s_t_a_l_l_a_t_i_o_n _G_u_i_d_e. The information listed here is product-specific; use it with the installation guide to install this product. _N_O_T_E: Under the 7.2 release, the C++ compiler front-ends are packaged in their own subsystem on a separate CD. For proper installation, you must install _c_o_m_p_i_l_e_r__d_e_v, _c_o_m_p_i_l_e_r__e_o_e, _c++__e_o_e and _c++__d_e_v from the IRIX Development - 3 - Foundation CD, as well as _c++__f_e from the MIPSpro C++ Compiler CD. The runtime libraries (DSOs) in the compiler_eoe and c++_eoe subsystems are identical to what was shipped on the corresponding IRIX releases and are provided as a convenience. However, the subsystems will appear as upgrades under inst, because changes have been made to certain non- runtime library files. If, however, you need the latest runtime library fixes you must install the subsystems from patch 2016 on top of this image. _c++__f_e (On MIPSpro C++ CD) contains: +o _f_e_c_c, the 64-bit and n32 C++ compiler frontend. +o _e_d_g_c_p_f_e, the 32-bit C++ compiler frontend. +o _e_d_g_c_p_f_e._e_h, the 32-bit C++ compiler frontend with support for exception handling. +o Online manual page for _C_C(1). _c++__d_e_v (On IRIX Development Foundation) contains: +o _C_C, the C++ compiler driver (not to be confused with _c_c). +o The utilities _e_d_g__p_r_e_l_i_n_k, _c++_p_a_t_c_h and _c++_f_i_l_t. +o For users wishing to use the old frontend, _c_f_r_o_n_t, a language translator for C++-to-C translation, and the utilities _m_a_r_k_c++, _p_t_c_o_m_p, and _p_t_l_i_n_k. (_N_O_T_E: tttthhhheeee ccccffffrrrroooonnnntttt----bbbbaaaasssseeeedddd ccccoooommmmppppiiiillllaaaattttiiiioooonnnn ssssyyyysssstttteeeemmmm iiiissss oooobbbbssssoooolllleeeesssscccceeeennnntttt,,,, aaaannnndddd wwwwiiiillllllll bbbbeeee rrrreeeemmmmoooovvvveeeedddd iiiinnnn aaaa ffffuuuuttttuuuurrrreeee rrrreeeelllleeeeaaaasssseeee). +o The libraries _l_i_b_c_o_m_p_l_e_x._a, and _l_i_b_m_a_n_g_l_e._a. +o Include files specific to C++. +o These release notes. +o _C++ _P_r_o_g_r_a_m_m_e_r'_s _G_u_i_d_e, which includes the hard-copy _C_C(1) manual page. - 4 - The 32-bit C++ libraries /_u_s_r/_l_i_b/_l_i_b_C._s_o and /_u_s_r/_l_i_b/_l_i_b_C_s_u_p._s_o are installed in the subsystem _c++__e_o_e._s_w._l_i_b. This allows application libraries written in C++ to be used on systems that do not have C++ installed. Note that these libraries are dynamic shared objects and not an archive. There are also non-shared archive form of the libraries, /_u_s_r/_l_i_b/_n_o_n_s_h_a_r_e_d/_l_i_b_C._a, and /_u_s_r/_l_i_b/_n_o_n_s_h_a_r_e_d/_l_i_b_C_s_u_p._a. Note: The 64-bit and n32 versions of these libraries are available in /_u_s_r/_l_i_b_6_4/ and /_u_s_r/_l_i_b_3_2/ directories respectively. Note: Packaged with this software is a separate sheet that contains the Software License Agreement. This software is provided to you solely under the terms and conditions of the Software License Agreement. Please take a few moments to review the Agreement. 1.2 _R_e_l_e_a_s_e__I_d_e_n_t_i_f_i_c_a_t_i_o_n__I_n_f_o_r_m_a_t_i_o_n_ Following is the release identification information for the 7.2 C++ Compiler. C++ Compiler SSSSooooffffttttwwwwaaaarrrreeee OOOOppppttttiiiioooonnnn PPPPrrrroooodddduuuucccctttt 7.2 VVVVeeeerrrrssssiiiioooonnnn SC4-C++-7.2 PPPPrrrroooodddduuuucccctttt CCCCooooddddeeee IRIX 6.2 (or higher) IRIX Development Foundation 1.0 SSSSooooffffttttwwwwaaaarrrreeee RRRReeeeqqqquuuuiiiirrrreeeemmmmeeeennnnttttssss 1.3 _O_n_l_i_n_e__R_e_l_e_a_s_e__N_o_t_e_s After you install the online documentation for a product (the _r_e_l_n_o_t_e_s subsystem), you can view the release notes on your screen. If you have a graphics system, select ``Release Notes'' from the Tools submenu of the Toolchest. This displays the _g_r_e_l_n_o_t_e_s(1) graphical browser for the online release notes. Refer to the _g_r_e_l_n_o_t_e_s(1) man page for information on options to this command. If you do not have a graphics system, you can use the _r_e_l_n_o_t_e_s command. Refer to the _r_e_l_n_o_t_e_s(1) man page for accessing the online release notes. - 5 - 1.4 _P_r_o_d_u_c_t__S_u_p_p_o_r_t Silicon Graphics, Inc., provides a comprehensive product support and maintenance program for its products. If you are in the U.S. or Canada and would like support for your Silicon Graphics-supported products, contact the Technical Assistance Center at 1-800-800-4SGI. If you are outside the U.S. or Canada, contact the Silicon Graphics subsidiary or authorized distributor in your country. 1.5 _C_+_+__C_o_m_p_i_l_e_r__S_u_b_s_y_s_t_e_m_s Following is a description of the C++ Compiler subsystems: _c++__d_e_v._s_w._c++ The C++ driver and associated tools _c++__d_e_v._s_w._l_i_b C++ demangling and complex 32-bit libraries _c++__d_e_v._s_w._l_i_b_r_w Rogue Wave (TM) Tools.h++ (TM) 32-bit library _c++__d_e_v._s_w._l_i_b_n_s Non_shared C++ 32-bit runtime library _c++__d_e_v._s_w_3_2._l_i_b C++ N32 demangling and complex libraries _c++__d_e_v._s_w_3_2._l_i_b_r_w Rogue Wave (TM) Tools.h++ (TM) N32-bit library _c++__d_e_v._s_w_6_4._l_i_b C++ 64-bit demangling and complex libraries _c++__d_e_v._s_w_6_4._l_i_b_r_w Rogue Wave (TM) Tools.h++ (TM) 64-bit library _c++__d_e_v._h_d_r._l_i_b Standard C++ header files _c++__d_e_v._h_d_r._l_i_b_r_w Rogue Wave (TM) Tools.h++ (TM) library header files _c++__d_e_v._m_a_n._c++ Man pages for C++ and the standard C++ header files _c++__d_e_v._m_a_n._l_i_b_r_w Man pages for the Rogue Wave (TM) Tools.h++ (TM) library - 6 - _c++__d_e_v._m_a_n._r_e_l_n_o_t_e_s These release notes _c++__d_e_v._b_o_o_k_s._c++__P_G C++ Language System Programmer's Guide 1.6 _L_i_c_e_n_s_i_n_g__I_n_f_o_r_m_a_t_i_o_n 1.6.1 _I_n_t_r_o_d_u_c_t_i_o_n Your copy of the MIPSpro C++ Compiler requires a software license in order to operate. This section defines some important software licensing terms, describes the basic procedure for obtaining, installing, and testing a software license for MIPSpro C++ Compiler, and lists a web site, addresses, and phone numbers that you can use to contact Silicon Graphics License Administration. For more information about installing and troubleshooting software licenses you can look in the CD liner notes or visit the web page: http://www.sgi.com/Support/Licensing/install_docs.html on Silicon Graphics' licensing website: http://www.sgi.com/Products/license.html For in depth detail on FLEXlm licensing, see the FLEXlm User's Guide, which covers using and administering FLEXlm software licenses. The FLEXlm User's Guide, is included in the system software documentation; the online InSight version is in the subsystem license_eoe.books.FlexLM_UG which is on the IRIX Development Foundation CD. Your purchased software is delivered with a label that includes a temporary license and an Entitlement ID. The temporary license allows you to use the software until you obtain your permanent license. However, your entitlement ID number makes it possible to obtain your permanent license instantly through Silicon Graphics' licensing website or email autobot. For WEB site and email address see "Contacting Silicon Graphics License Administration" at the end of this chapter of the release notes. - 7 - 1.6.2 _A__F_e_w__D_e_f_i_n_i_t_i_o_n_s A software license is a collection of information that, after installation, allows you to use a licensed software product on one or more systems. The software license information includes the license type, the license expiration date, a license password, a system ID number (/etc/sysinfo -s), and additional information concerning the license and licensed software. Floating licenses have the host name (/sbin/uname -n) as part of the license. There are two types of software licenses, node-locked and floating: 1.6.2.1 _n_o_d_e_-_l_o_c_k_e_d A node-locked license is installed on a particular system (node) and allows the licensed software to run on that system. For this release there are four different types of nodelocked licenses each corresponding to a different product pricing tier. +o The first tier allows you to run MIPSpro C on a system of two or less processors. It contains "CPU 2" in its VENDOR STRING field. +o The second tier allows you to run MIPSpro C on a system of eight or less processors. It contains "CPU 8" in its VENDOR STRING field. +o The third tier allows you to run MIPSpro C on a system of 32 or less processors. It contains "CPU 32" in its VENDOR STRING field. +o The fourth tier allows you to run MIPSpro C on a system of any number of processors. It does not contain a VENDOR STRING field. - 8 - 1.6.2.2 _f_l_o_a_t_i_n_g A floating license allows the licensed software to run on one or more systems in the network simultaneously. The number of systems (nodes) allowed is included in the software license information. When an application requires a license from a license server, the floating license points the client to the license server (server name and license file path are included with the license and copied on all client systems). The FLEXlm license daemon, lmgrd, is responsible for checking out/in licenses (tokens) to/from client systems. As long as the number of licenses checked out to clients at a given time is less than the encrypted maximum number of concurrent users no user is denied access. Once the maximum number is reached, the next request for a license will be denied. Floating licenses have the advantage of cost, since a license can be shared over many infrequent users, but they are harder to install and administer. Floating license check-out times can also vary depending on the load of the network and the time needed to reach the license server. 1.6.2.3 _E_n_t_i_t_l_e_m_e_n_t__I_D The Entitlement ID is a 15 digit number (shipped with the software) which allows your permanent license request to be processed and approved in seconds. 1.6.3 _O_b_t_a_i_n_i_n_g__a_n_d__I_n_s_t_a_l_l_i_n_g__a__S_o_f_t_w_a_r_e__L_i_c_e_n_s_e This section explains the procedure for obtaining and installing a software license: 1.6.3.1 _M_a_k_e _c_e_r_t_a_i_n _y_o_u _h_a_v_e _y_o_u_r _s_o_f_t_w_a_r_e _l_i_c_e_n_s_e _i_n_f_o_r_m_a_t_i_o_n Software license information is distributed in several ways: by WEB page, email, FAX, postal mail, or on sheets of paper included with the product. - 9 - If you are updating to this release of MIPSpro C++ Compiler from an older release you need to obtain and install a new license. If you have received both a temporary license and a permanent software license, install the permanent license; do not install the temporary license. 1.6.3.2 _I_d_e_n_t_i_f_y _t_h_e _s_y_s_t_e_m _o_n _w_h_i_c_h _y_o_u _w_i_l_l _i_n_s_t_a_l_l _t_h_e _s_o_f_t_w_a_r_e _l_i_c_e_n_s_e. Because software license information usually must be installed on a particular system, follow these guidelines: If the System ID field says ``ANY,'' then you can install the license on any system you choose. Install a license on the machine which has a system ID ( /etc/sysinfo -s ) which matches the system ID in the license. 1.6.3.3 _I_n_s_t_a_l_l _t_h_e _s_o_f_t_w_a_r_e _l_i_c_e_n_s_e (_t_e_m_p_o_r_a_r_y _o_r _p_e_r_m_a_n_e_n_t). Licenses typically come with complete license installation instructions. Follow these instructions to install the license. For more detailed license installation and trouble shooting information see the web page: http://www.sgi.com/Support/Licensing/install_docs.html Check the ``license type'' listed in the software license information to find out whether the license is a node-locked license or a floating license. The installation procedure depends on the license type: You can install the license "manually" or use the LicenseManager(1M) tool. You can bring up LicenseManager by choosing ``License Manager'' from the System toolchest. If the license is a floating license, you may need to configure the system on which you plan to install the license as a license server. - 10 - 1.6.3.4 _V_e_r_i_f_y _t_h_a_t _t_h_e _s_o_f_t_w_a_r_e _l_i_c_e_n_s_e _h_a_s _b_e_e_n _s_u_c_c_e_s_s_f_u_l_l_y _i_n_s_t_a_l_l_e_d. To verify that the software license is working, try running the MIPSpro C++ Compiler. The licensed program in this product is: CC(1). The FEATURE NAME in the license of this product appears as cpp. For this release, C++ compilations will not be terminated if the license is absent or incorrectly installed. However, a warning message similar to the following will be displayed: %CC -c foo.cpp Cannot find license file (-1,73:2) No such file or directory The MIPSpro C++ Compiler (license FEATURE string = cpp) requires a license password. For license installation and trouble shooting information visit the web page: http://www.sgi.com/Support/Licensing/install_docs.html To obtain a Permanent license (proof of purchase required) or an Evaluation license please visit our license request web page: http://www.sgi.com/Products/license.html or send a blank email message to: license@sgi.com In North America, Silicon Graphics' customers may request Permanent licenses by sending a facsimile to: (650) 932-0537 or by calling our technical support hotline 1-800-800-4SGI If you are Outside of North America or you are not a Silicon Graphics support customer then contact your local support provider. - 11 - 1.6.4 _C_o_n_t_a_c_t_i_n_g__S_i_l_i_c_o_n__G_r_a_p_h_i_c_s__L_i_c_e_n_s_e__A_d_m_i_n_i_s_t_r_a_t_i_o_n If you are connected to the internet then you can request a permanent license from any country in the world using either of the following methods: * WEB: Go the the web site: http://www.sgi.com/Products/license.html Look under the "License Request" section. * email: Send a blank email message to license@sgi.com You will be sent back a blank email license request template with full instructions. If are not connected to the internet and need to obtain a software license, fill out the Software License Registration sheet that was included inside the CD liner notes with the software (or the replica in the Network License System Administration Guide). Send or FAX the filled out Software License Registration sheet to Silicon Graphics License Administration or your local service provider. After your request is received by Silicon Graphics or your local service provider, you should receive a software license within two business days. In the United States and Canada, Silicon Graphics License Administration provides software license information to Silicon Graphics customers. You can contact Silicon Graphics License Administration in these ways: * FAX: (650) 932-0537 * Mail: Software Licensing M/S 134 Silicon Graphics, Inc. P.O. Box 7311 Mountain View, CA 94039-9600 In an emergency, you can telephone Silicon Graphics at (800) 800-4744. If you are not in the United States or Canada, or if you purchased the system or software from a vendor other than Silicon Graphics, please contact your local service provider. - 12 - 1.7 _I_n_s_t_a_l_l_a_t_i_o_n__M_e_t_h_o_d All of the subsystems for the C++ Compiler can be installed using _i_n_s_t from IRIX. For the details of this procedure, consult the _1._0 _I_R_I_X _D_e_v_e_l_o_p_m_e_n_t _F_o_u_n_d_a_t_i_o_n release notes. 1.8 _N_e_w__F_e_a_t_u_r_e_s 1.8.1 _M_I_P_S_p_r_o__A_u_t_o__P_a_r_a_l_l_e_l_i_z_i_n_g__O_p_t_i_o_n The MIPSpro Auto Parallelizing Option is a new product which provides support for automatic parallelization for the MIPSpro 7.2 family of compilers. Similar to Power C Analyzer and Power Fortran Analyzer, Auto Parallelizing Option will automatically try parallelize C, C++, Fortran77 and Fortran90 programs when -pfa or -pca is specified on he compiler command-line. One copy of Auto Parallelizing Option works for all four languages. It only supports the 64-bit (-64) and new high performance 32-bit (-n32) ABI's. The old 32-bit ABI (-32) is not supported by this product. 1.8.2 _D_a_t_a__D_i_s_t_r_i_b_u_t_i_o_n__D_i_r_e_c_t_i_v_e_s The MIPSpro 7.2 compiler operating in the n32 and 64-bit mode provides for data distribution pragmas such as distribute, and distribute-reshape, which allow for explicit data parallelism to be exploited in a multi-processing environment. This is in addition to the multi-processing MP pragmas for which support has been provided since 7.1. The programmer's guide describes the data distribution pragmas and their use on multiprocessing machines such as the Origin series. 1.8.3 _N_e_w__P_a_r_a_l_l_e_l__P_r_a_g_m_a__O_p_t_i_o_n_s MIPSpro 7.2 now supports some new optional arguments to the pfor parallel pragmas when -mp is specified on the compiler command-line: onto, nest, local, lastlocal, affinity, and reduction. Also, the synchronize pragma can now be used outside of parallel regions. See he MIPSpro C and C++ Pragmas document for more information on these parallel pragmas. - 13 - 1.8.4 _N_e_w__S_y_m_b_o_l__S_t_o_r_a_g_e__D_i_r_e_c_t_i_v_e_s Two new directives have been added in MIPSpro 7.2 to control the way symbols are stored: ALIGN_SYMBOL and FILL_SYMBOL. The ALIGN_SYMBOL directive aligns the start of symbol at a specified alignment boundary. The FILL_SYMBOL directive pads symbol with additional storage so that the symbol is assured not to overlap with any other data item within the storage of the specified size. The additional padding required is divided between each end of the specified variable. 1.8.5 _V_a_r_i_a_b_l_e__L_e_n_g_t_h__A_r_r_a_y_s MIPSpro 7.2 now supports variable length arrays. Array dummy arguments and local arrays can now be declared as variable length arrays rather than as pointers. This allows the compiler to make assumptions about aliasing and can allow more optimizations to be applied to code containing references to the array. This is particularly beneficial for parallelization. The syntax for variable length arrays is: int foo( int n, float a[n][n] ) { float b[n]; } In the example above, dummy argument a and local variable b are both variable length arrays. Variable length arrays are provided in C++ as an experimental feature and may not work in the presence of C++ features such as templates and exceptions. 1.8.6 _F_r_e_q_u_e_n_c_y__h_i_n_t__p_r_a_g_m_a_s MIPSpro 7.2 now supports a new pragma "#pragma mips_freqency_hint" that is used to tell the compiler that a branch or function is rarely executed. The compiler uses this information to make better optimization decisions. A branch can be marked a infreqently taken in this fashion: if ( a < b ) { #pragma mips_frequency_hint NEVER printf("error condition0); } While a function can be so marked this way: - 14 - void handle_error( int i ); #pragma mips_frequency_hint NEVER handle_error Frequency information about a function gets propogated to all instances where the function is used. So a branch that contains a call to an infrequent function is considered infrequently executed itself. 1.8.7 _P_R_I_N_T_F_L_I_K_E__l_i_n_t__s_t_y_l_e__c_o_m_m_e_n_t This comment applies lint style check to the first (n-1) arguments as usual. The nth argument is interpreted as a printf format string that is used to check the remaining arguments. 1.8.8 _S_C_A_N_F_L_I_K_E__l_i_n_t__s_t_y_l_e__c_o_m_m_e_n_t This comment applies lint style check to the first (n-1) arguments as usual. The nth argument is interpreted as a scanf format string that is used to check the remaining arguments. 1.8.9 _-_a_r__f_l_a_g_. ar(1) should not be invoked to create an archive of c++ objects. Instead the -ar flag of CC(1) should be used to create an archive. This flag will instantiate all the necessary template entities before creating the archive. See -ar option in CC(1) man page. 1.9 _N_e_w__B_o_o_k_s MIPSPro C and C++ Pragmas 1.10 _C_o_m_p_a_t_i_b_i_l_i_t_y__w_i_t_h__c_+_+__7_._1 The 7.2 C++ compiler operating in 32-bit mode as well as n32 and 64-bit mode is fully link-compatible with code compiled with C++ 7.1 with the following exceptions (n32 and 64-bit mode only): 1.10.1 _-_e_x_p_e_r_i_m_e_n_t_a_l__f_l_a_g__n_o__l_o_n_g_e_r__s_u_p_p_o_r_t_e_d The flag -experimental, which could be used with the 7.1 compiler to invoke an experimental version which supported namespaces, is no longer supported, since the released compiler now supports namespaces and other new features. - 15 - 1.10.2 _R_u_n_t_i_m_e _c_h_a_n_g_e _i_n _s_e_m_a_n_t_i_c_s _o_f _c_o_p_y _a_s_s_i_g_n_m_e_n_t _o_p_e_r_a_t_o_r _c_a_l_l_s This is a change in runtime behavior! It only affects you if you define an assignment operator in class B, but the type of argument that this operator accepts is not of type B. struct A {}; struct B { B(); B& operator= (const A&); operator A& () const; }; main() { B b1, b2; b1 = b2; return 0; } With the 7.1 compilers, the statement b1 = b2 generated a call to the conversion operator function "operator A& () const" to convert a B object to an object of type A followed by a call to operator function "B& operator= () const(A&)" to copy the A object. This behavior was incorrect since the function "B& operator= (const A&)" is not a copy assignment operator. A copy assignment operator can take exactly one parameter of the form A, A&, const A&, volatile A&, or const volatile A&. With the 7.2 compilers, the frontend will implicitly generate a copy assignment operator of the form B::operator=(const B &) which will perform a bitwise copy. This may result in completely different runtime behavior. The compiler will warn in such cases with the following message: "t.c";, line 12: warning(3149): class "B" has no copy assignment operator. A copy assignment operator of the form "B::operator=(const B &)" has been implicitly defined. The implicitly defined copy assignment operator will perform a bitwise copy. Previous compiler versions may have used assignment operator functions defined in this class with conversion operators as copy assignment operators. This change may lead to different runtime behavior. Define a copy assignment operator if necessary. The suggested approach to fix the problem is to define a copy assigment operator that performs the copy. In the above test case, one could add a member function in B: - 16 - B& operator= (const B& arg) { *this = ( const A&) arg; // Convert the argument to a 'A' object and // then call the operator= function. } 1.10.3 _P_r_e_v_i_o_u_s_l_y__u_n_d_i_a_g_n_o_s_e_d__e_r_r_o_r__o_n__n_o_n_m_e_m_b_e_r__o_p_e_r_a_t_o_r_s Non-member operators have always required at least one class (or reference to class) parameter. Earlier compilers have occasionally failed to diagnose this problem, particularly when this happened in template functions. C++ 7.2 will always give you a compile time error for this. template <class T> class Ptr{ }; template <class T&> int operator!=(Ptr<T>* a, Ptr<T>* b); //Should be an error The fix is to remove any such functions; they could not possibly have been invoked in earlier compilers, so removing them cannot change program behavior. 1.10.4 _A_m_b_i_g_u_i_t_y__w_i_t_h__c_o_n_d_i_t_i_o_n_a_l__o_p_e_r_a_t_o_r This issue pertains to ?: expressions where the left and right arms are of different types. For example: struct A { A(); A(int); operator int(); }; void foo(int i,int j) { i ? A() : j; //AMBIGUOUS in 7.2 -n32 } "foo.c", line 8: error(1324): more than one operator"?" matches these operands: built-in operator "expression ? class : class" built-in operator "expression ? arithmetic : arithmetic" operand types are: A : int Recent changes to Ansi C++ draft standard may have made this expression ambiguous. Please rewrite the expression to remove the ambiguity. To get the old behavior use the "-Wf,-old_conditional_operator_rules" flag. i ? A() : j; //AMBIGUOUS in 7.2 -n32 In the example above, the compiler could determine the - 17 - return type of the ?: in two ways: +o Convert the A() to an int and make the result of int type +o Convert the int to an A, and make the result of type A It is therefore an ambiguous construct. It used to be that the compiler would always prefer converting the A() to an int, but the standard now makes this ambiguous. The suggested way of making this code work with all compilers is to use an explicit cast to make the result type unambiguous. In this case, what was probably intended was: i ? (int)A() : j; The other choice would be: i ? A() : (A)j If you cannot change your source code, use the "-Wf,-old_conditional_operator_rules" flag. 1.10.5 _E_n_u_m_e_r_a_t_o_r_s__c_a_n_n_o_t__b_e__c_o_n_v_e_r_t_e_d__t_o__p_o_i_n_t_e_r_s An enum in C++ is not a numeric type, and there is no implicit conversion to a pointer. The 7.1 compiler failed to diagnose this error. enum fruit {orange}; void* p = orange; //This is an error "foo.c", line 2: error(1140): a value of type "fruit" cannot be used to initialize an entity of type "void *" void* p = orange; The way to fix this is to explicitly cast the enum to an int. enum fruit {orange}; void* p = (int)orange; //This is fine 1.10.6 _N_e_w__k_e_y_w_o_r_d_s There are four new reserved words in C++ 7.2: "typename", "explicit", "namespace", and "mutable". All existing code should be modified so that it does not use these words as identifiers. If for some reason you are unable to modify code that uses these reserved words (e.g. it's in a third party header), you can use any combination of the following options: -LANG:explicit=off, or -LANG:typename=off, or -LANG:namespace=off or -LANG:mutable=off Note that in a - 18 - future release "export" will also be made a keyword, so you should not be using this as an identifier. 1.10.7 _S_t_a_n_d_a_r_d__p_l_a_c_e_m_e_n_t__n_e_w__c_a_n_n_o_t__b_e__p_r_e_e_m_p_t_e_d A placement version of operator new used to be defined as follows in new.h: void *operator new(size_t, void* p); The library used to provide the obvious implementation: void *operator new(size_t, void* p) {return p; } The C++ standard now states that the standard version of placement operator new cannot be preempted. This allows us to provide an inline version of placement operator new in new.h: inline void *operator new(size_t, void* p) { return p; } One consequence of this is that if you explicitly define your own version of placement operator new (whether inline or out-of-line) you will get an error. In previous releases, it was possible to define your own version of placement operator new. For example: #include <new.h> inline void *operator new(size_t, void* p) { return p; } will get the following error: "foo.c", line 2: error(1220): function "operator new(size_t, void *)" has already been defined inline void *operator new(size_t, void* p) { return p; } Note that this does not prevent you from defining your own versions of placement operator new which have parameter profiles which are different from the standard All of the above discussion also applies to operator new []. - 19 - 1.11 _L_a_n_g_u_a_g_e__S_u_p_p_o_r_t_e_d 1.11.1 _N_e_w__L_a_n_g_u_a_g_e__F_e_a_t_u_r_e_s__A_c_c_e_p_t_e_d The following features not in the C++ Annotated Reference Manual but in the current X3716/WG21 Working Paper are accepted (for the 64-bit and n32 compilers only): +o The dependent statement of an "if", "while", "do", or "for" statement is considered to be a scope, and the restriction on having such a dependent statement be a declaration is removed. +o The draft C++ standard specifies that the scope of a variable declared in the for-init-statement of a for- loop is the scope of the loop, not the surrounding scope. This feature is now implemented, but because this is the first compiler release to implement it, and because the change could break a lot of existing code, it has been implemented only if -LANG:ansi-for-init- scope=on is specified on the command line. The default behavior will be changed in a future release (possibly in the next release). We strongly recommend that you start compiling with the -LANG:ansi-for-init-scope=on to find and correct code that does not conform to the draft standard. +o Qualified names are allowed in elaborated type specifiers. +o A global-scope qualifier is allowed in member references of the form x.::A::B or p->::A::B +o The precedence of the third operand of the ? operator is changed. +o If control reaches the end of the main routine, and main has an integral return type, it is treated as if a "return 0" statement were executed. +o Pointers to arrays with unknown bounds as parameter types are diagnosed as errors. +o A functional-notation cast of the form "A()" can be used even if A is a class without a nontrivial constructor. The temporary created gets the same default initialization to zero as a static object of the class type. +o A cast can be used to select one out of a set of overloaded functions when taking the address of a - 20 - function. +o Template friend declarations and definitions are permitted in class definitions and class template definitions. +o Type template parameters are permitted to have default arguments. +o Function templates may have nontype template parameters. +o A reference to const volatile cannot be bound to an rvalue. +o Qualification conversions such as conversion from (T**) to T const * const * are allowed. +o Static data member declarations can be used to declare member constants. +o wchar_t is recognized as a keyword and a distinct type. +o bool is recognized. +o RTTI (runtime type-identification), including dynamic_cast and the typeid operator, is implemented. +o Array new and delete are implemented. +o New-style casts (static_cast, reinterpret_cast, and const-cast) are implemented. +o Definition of a nested class outside its enclosing class is allowed. +o "mutable" is accepted on nonstatic data member declarations. +o Namespaces are implemented, including "using" declarations and directives. Access declarations are broadened to match the corrsponding "using" declarations. +o Explicit instantiation of templates is implemented. +o The "typename" keyword is recognized. +o "explicit" is accepted to declare nonconverting constructors. - 21 - +o Member templates are supported. +o The new specialization syntax (using "template<>") is implemented. +o Cv-qualifiers are retained on rvalues (in particular, on function return values). +o The distinction between trivial and nontrivial constructors has been implemented, as has the distinction between PODs and non-PODs with trivial constructors. +o The linkage specification is treated as part of the function type (affecting function overloading and implicit conversions). +o A typedef name may be used in an explicit destructor call. +o Placement delete is implemented. +o enum types are considered to be non-integral types. +o Partial specialization of class templates is implemented. 1.11.2 _N_e_w__L_a_n_g_u_a_g_e__F_e_a_t_u_r_e_s__N_o_t__A_c_c_e_p_t_e_d The following features not in the ARM but in the X3J16/WG21 Working Paper are not accepted: +o It is not possible to overload operators using functions that take enum types and no class types. +o The new lookup rules for member references of the form x.A and p->A::B are not yet implemented. +o enum types cannot contain values larger than can be contained in an int. +o reinterpret_cast does not allow casting a pointer to member of one class to a pointer to member of another class. +o Explicit qualification of template functions is not implemented. +o The new template compilation model is not yet implemented. - 22 - +o In a reference of the form f()->g(), with g a static member function, f() is not evaluated. +o Class name injection is not implemented. +o Putting a try/catch around the initializers and body of a constructor is not implemented. +o The notation ::template (and ->template, etc.) is not implemented. +o Template template parameters are not implemented. +o Certain restrictions are not yet enforced on the use of pointer-to-function types that involve exception specifications. +o "Koenig lookup" of function names on calls is not implemented. +o Finding friend functions of the argument types on name lookup on the function name in calls is not implemented. +o Digraphs and operator keywords are not recognized. +o Covariant return types are not supported. +o "extern inline" is not implemented. 1.11.3 _F_e_a_t_u_r_e__M_a_c_r_o_s A number of language features can be disabled via commandline options. When this happens certain macros which are normally defined remain undefined. These can then be used in #ifdefs in source files to do conditional compilation based on whether or not these features are enabled. The following feature macros are defined or not depending on whether or not the corresponding feature is enabled. +o __EXCEPTIONS is defined unless -LANG:exceptions=off is specified. +o _BOOL is defined unless -LANG:bool=off is specified. +o _WCHAR_T_IS_KEYWORD is defined unless -LANG:wchar_t=off is specified. +o _MUTABLE_IS_KEYWORD is defined unless -LANG:mutable=off is specified. - 23 - +o _EXPLICIT_IS_KEYWORD is defined unless -LANG:explicit=off is specified. 1.12 _C_+_+__C_o_m_p_i_l_e_r__F_i_l_e_s After installing the C++ Compiler images from both the MIPSpro C++ CD and the IRIX Development Foundation CD, you should have the following files: /_u_s_r/_b_i_n/_C_C C++ compiler driver /_u_s_r/_l_i_b_3_2/_c_m_p_l_r_s/_f_e_c_c The n32/64-bit compiler frontend /_u_s_r/_l_i_b_3_2/_c_m_p_l_r_s/_b_e The n32/64-bit compiler backend /_u_s_r/_l_i_b/_D_C_C/_e_d_g_c_p_f_e The 32-bit compiler frontend /_u_s_r/_l_i_b/_D_C_C/_e_d_g__p_r_e_l_i_n_k The "prelinker" which controls template instantiation /_u_s_r/_l_i_b/_c++/_c++_p_a_t_c_h C++ post-processor /_u_s_r/_i_n_c_l_u_d_e/_C_C C++ include file directory /_u_s_r/_i_n_c_l_u_d_e/_C_C/_e_x_c_e_p_t_i_o_n._h Entities such as _b_a_d__e_x_c_e_p_t_i_o_n, _s_e_t__t_e_r_m_i_n_a_t_e, and _s_e_t__u_n_e_x_p_e_c_t_e_d required for exception handling. /_u_s_r/_i_n_c_l_u_d_e/_C_C/_s_t_d_e_x_c_e_p_t._h Definition of the _s_t_d::_e_x_c_e_p_t_i_o_n class, which is the base class for any exceptions thrown by the C++ runtime /_u_s_r/_l_i_b/_l_i_b_c_o_m_p_l_e_x._a Non-template C++ complex math library for 32-bit compiler /_u_s_r/_l_i_b_3_2/_l_i_b_C_o_m_p_l_e_x._a Template-based C++ complex math library for n32 compiler /_u_s_r/_l_i_b_3_2/_l_i_b_c_o_m_p_l_e_x._a Non-template C++ complex math library for n32 - 24 - compiler /_u_s_r/_l_i_b_6_4/_l_i_b_C_o_m_p_l_e_x._a Template-based C++ complex math library for 64-bit compiler /_u_s_r/_l_i_b_6_4/_l_i_b_c_o_m_p_l_e_x._a Non-template C++ complex math library for 64-bit compiler /_u_s_r/_l_i_b/_c++/_l_i_b_m_a_n_g_l_e._a C++ name-demangler library /_u_s_r/_l_i_b/_c++/_c++_f_i_l_t C++ name-demangling utility /_u_s_r/_c_a_t_m_a_n/_u__m_a_n/_c_a_t_1/_C_C._z C++ compiler driver manual page /_u_s_r/_r_e_l_n_o_t_e_s/_C_C C++ Release Notes directory The following files are present only for supporting the old _c_f_r_o_n_t-based compiler, and will be unavailable in future releases: /_u_s_r/_l_i_b/_c++/_c_f_r_o_n_t The old C++ Translator, for use with -use_cfront /_u_s_r/_l_i_b/_c++/_m_a_r_k_c++ The old utility to identify C++ files for _d_b_x(_1) /_u_s_r/_l_i_b/_c++/_p_t_c_o_m_p Old tool for Template support for cfront /_u_s_r/_l_i_b/_c++/_p_t_l_i_n_k Old tool for Template support for cfront "Note:" The C++ libraries for the 32-bit compiler /_u_s_r/_l_i_b/_l_i_b_C._s_o and /_u_s_r/_l_i_b/_l_i_b_C_s_u_p._s_o are installed from the subsystem _c++__e_o_e._s_w._l_i_b. This allows application libraries written in C++ to be used on systems that do not have C++ installed. The corresponding libraries for the 64-bit and n32 compilers are in the directories /_u_s_r/_l_i_b_6_4 and /_u_s_r/_l_i_b_3_2 respectively and are installed from the subsystems _c++__e_o_e_6_4._s_w._l_i_b and _c++__e_o_e_3_2._s_w._l_i_b respectively. - 25 - 1.13 _C_+_+__C_o_m_p_i_l_e_r__D_o_c_u_m_e_n_t_a_t_i_o_n Silicon Graphics has produced the following C++ Compiler documentation: +o _C_C(1) man page (printed and online version) +o _7._2 _C++ _R_e_l_e_a_s_e _N_o_t_e_s (this online document) +o Online manual (see the packing manifest above) 1.14 _R_u_n_t_i_m_e__P_e_r_f_o_r_m_a_n_c_e__E_n_h_a_n_c_e_m_e_n_t_s The 7.2 C++ compiler operating in the n32 and 64-bit mode provides improved runtime performance. In particular, performance improvements from 10% to 50% over 7.1 are achieved by enhancements in inlining, alias analysis, scalar and struct optimizations, and loop optimizations. The MIPSpro Compiling And Performance Tuning Guide provides tips on how to get the best runtime performance from C and C++ programs. Additionally the following option is provided for improved analysis of functions which take parameters by const reference. 1.14.1 _c_o_n_s_t _r_e_f_e_r_e_n_c_e _p_a_r_a_m_e_t_e_r _o_p_t_i_m_i_z_a_t_i_o_n _w_i_t_h -_L_A_N_G:_a_l_i_a_s__c_o_n_s_t Consider the following example: extern void pass_by_const_ref(const int& i); int test(){ //This requires -LANG:alias_const to get the performance enhancements int i = 10 int j = 15 pass_by_const_ref(i); pass_by_const_ref(j); return i + j; } In the example above, the compiler determines that the function pass_by_const_ref does NOT modify its formal parameter i: ie the parameter i passed by const reference - 26 - does NOT get modified in the function. Consequently the compiler can forward propagate the values of i and j to the return statement, whereas it would otherwise have had to reload the values of i and j after the two calls to pass_by_const_ref. (_N_O_T_E: FFFFoooorrrr tttthhhhiiiissss ooooppppttttiiiimmmmiiiizzzzaaaattttiiiioooonnnn ttttoooo wwwwoooorrrrkkkk ccccoooorrrrrrrreeeeccccttttllllyyyy,,,, bbbbooootttthhhh tttthhhheeee ccccaaaalllllllleeeerrrr aaaannnndddd tttthhhheeee ccccaaaalllllllleeeeeeee hhhhaaaavvvveeee ttttoooo bbbbeeee ccccoooommmmppppiiiilllleeeedddd wwwwiiiitttthhhh ----LLLLAAAANNNNGGGG::::aaaalllliiiiaaaassss____ccccoooonnnnsssstttt....). The reason this option is not on by default is that the user can legally cast away the const qualifier and modify the const parameter. With this option the compiler makes an effort to issue warnings when the callee casts away the const and modifies the parameter. For example, void f(const int &x) {int *y = (int *) &x; *y = 99;} int main() { int z; f(z); // call to f does modify z; Hence z needs to be reloaded after the call return z; } With the above example, and -LANG:alias_const, the compiler gives a warning: Compiling f__GRCi "ex9.C", line 2 (col. 28): warning(3334): cast to type "int *" may not be safe in presence of -LANG:alias_const. Make sure you are not casting away const to MODIFY the parameter For the above example, it is NOT safe to use -LANG:alias_const. However, if the user specifies the "mutable" keyword then this const optimization is disabled. For example: - 27 - class C { public: mutable int p; void f() const { p = 99;} //mutable data member can be modified // by a const function int getf() const { return p;} }; int main() { C c; c.f();// even with -LANG:alias_const, f() can modify c.p return c.getf(); }; The above example illustrates that in general, alias options should only be used with programs for which they are safe. For instance, -OPT:alias=unnamed and -OPT:alias=restrict are optimizations which are only safe for programs which satisfy the aliasing assumptions made by these optimizations. Hence such options are NOT default for C++ and should be used with caution. 1.14.2 _C_o_m_p_i_l_i_n_g__w_i_t_h__-_L_A_N_G_:_e_x_c_e_p_t_i_o_n_s_=_o_f_f__f_o_r__N_O_N_-_E_H__c_o_d_e For code that doesn't throw/catch/propogate exceptions it is beneficial to compile with -LANG:exceptions=off. This permits optimizations that would otherwise be conservative around regions of code that may throw exceptions. 1.15 _S_t_a_n_d_a_r_d__T_e_m_p_l_a_t_e__L_i_b_r_a_r_y This release includes the Standard Template Library (STL), a generic container, algorithm, and iterator library. At present all STL code is in the form of header files, which are located in the directory /_u_s_r/_i_n_c_l_u_d_e/_C_C. This directory is in the standard include path. This implementation of the STL is backward compatible with the free HP implementation, except that the definitions of stack, queue, and priority_queue have been changed to reflect the interface described by the draft C++ standard. New features, not part of the free HP implementation, include hash tables (defined in _h_a_s_h__s_e_t._h and _h_a_s_h__m_a_p._h), - 28 - singly linked lists (defined in _s_l_i_s_t._h), a scalable string representation (defined in _r_o_p_e._h) and high performance allocators (defined in _a_l_l_o_c._h). This implementation of the STL is exception-safe and thread-safe. Features present in this release, but that were not present in 7.1, include: +o Exception safety. All STL components are now exception safe. +o New container class: _r_o_p_e. A scalable string representation. +o New container class: _s_l_i_s_t. Singly linked lists. +o Member templates. You can now use the fully general form of containers' copy constructors and insert member functions. Note that this is only supported in the n32/64 compiler. +o New standard-conforming mechanism for accessing iterators' associated type information: _i_t_e_r_a_t_o_r__t_r_a_i_t_s. The algorithms _c_o_u_n_t, _c_o_u_n_t__i_f, and _d_i_s_t_a_n_c_e have been rewritten in terms of _i_t_e_r_a_t_o_r__t_r_a_i_t_s. Note that this is only supported in the n32/64 compiler. +o New algorithms: _c_o_p_y__n, _l_e_x_i_c_o_g_r_a_p_h_i_c_a_l__c_o_m_p_a_r_e__3_w_a_y, _p_o_w_e_r, _r_a_n_d_o_m__s_a_m_p_l_e, _r_a_n_d_o_m__s_a_m_p_l_e__n, _u_n_i_n_i_t_i_a_l_i_z_e_d__c_o_p_y__n. Allocators in this implementation differ in function and interface from allocators in the original STL documents. The default allocator, which is called _a_l_l_o_c, is thread- safe. All containers are parameterized by allocators, so, for example, _l_i_s_t<_i_n_t> is equivalent to _l_i_s_t<_i_n_t, _a_l_l_o_c>. Three other allocators are provided: +o _s_i_n_g_l_e__c_l_i_e_n_t__a_l_l_o_c is faster but not thread-safe. +o _p_t_h_r_e_a_d__a_l_l_o_c is intended for pthreads only. It has better performance for multithreaded code. Objects should be deallocated by the allocating thread. It is defined in _p_t_h_r_e_a_d__a_l_l_o_c._h. +o _m_a_l_l_o_c__a_l_l_o_c, which is preferable for use with Purify or other memory debugging tools. +o _d_e_b_u_g__a_l_l_o_c, an instrumenting allocator adaptor. It checks for improper deallocation calls in STL- - 29 - conformant containers. Ropes (_r_o_p_e._h in /_u_s_r/_i_n_c_l_u_d_e/_C_C) provide a scalable string implementation. They are ideally suited to applications which must handle arbitrarily long strings with consistent performance, but for which in-place single-character updates are rare. The time required to concatenate two ropes is almost independent of their length. The interface is similar to, but not identical to that of basic_string defined in the current C++ draft standard. The STL Programmer's Guide contains a more detailed description of both the rope interface, and the issues surrounding string representations in C++. The file _m_s_t_r_i_n_g._h, located in /_u_s_r/_i_n_c_l_u_d_e/_C_C, is not part of the STL. It is a public domain string class written by Modena, and it is included for the sake of convenience. It is not recommended for multithreaded use. 1.16 _N_e_w__t_e_m_p_l_a_t_e_-_b_a_s_e_d__c_o_m_p_l_e_x__n_u_m_b_e_r__l_i_b_r_a_r_y This release includes the template class _c_o_m_p_l_e_x, as described in in the draft C++ standard. Single-precision complex numbers are _c_o_m_p_l_e_x<_f_l_o_a_t>, double-precision are _c_o_m_p_l_e_x<_d_o_u_b_l_e>, and quad precision are _c_o_m_p_l_e_x<_l_o_n_g _d_o_u_b_l_e>. The template _c_o_m_p_l_e_x is declared in the header file _c_o_m_p_l_e_x._h. Note that this is a change from previous compiler releases: previous releases instead included a complex number class that was not a template, and that only supported double- precision complex numbers. If you are migrating code from an earlier compiler release, then you can either modify your code (by changing all instances of _c_o_m_p_l_e_x to _c_o_m_p_l_e_x<_d_o_u_b_l_e>) or else you can continue to use the non-template class. You can select the non-template complex class by defining the macro __N_O_N__T_E_M_P_L_A_T_E__C_O_M_P_L_E_X before including the header _c_o_m_p_l_e_x._h. The template-based complex class is only supported on the n32/64 compilers. If you are using the ucode (o32) compiler, then __N_O_N__T_E_M_P_L_A_T_E__C_O_M_P_L_E_X will be defined automatically. Regardless of whether you are using the newer template-based complex class or the older non-template class, the complex library is not automatically loaded by the C++ compiler. - 30 - You must explicitly provide a command-line option telling the compiler to link the complex library. (This is expected to change in a future release.) You must also include the math library, -_l_m. To use the newer, template-based complex library, include the options -lComplex -lm To use the older, non-template complex library, include the options -lcomplex -lm 1.17 _R_o_g_u_e__W_a_v_e__T_o_o_l_s_._h_+_+ Tools.h++ 7.03 is bundled with this release. The previous version of Tools.h++ is no longer supported. 1.18 _K_n_o_w_n__P_r_o_b_l_e_m_s__a_n_d__W_o_r_k_a_r_o_u_n_d_s This section describes the known problems with the current release of the C++ product and how to work around them. Some of the descriptions are followed by a Silicon Graphics, Inc., bug report number in the form (Bug #xxxxx). Unless stated otherwise, the bugs described below affect the 64-bit and n32 compilation modes. +o The standard library as described in the draft standard is not yet completely implemented. +o The standard header files without a .h suffix are not yet available. +o The names in the standard library are not yet in namespace std. +o CC does not inline sqrt by default (Bug #439787). Unlike cc, the n32 and 64-bit C++ compiler does not by default use built-in operations to compute square roots, nor does it treat functions from the standard math library as having no side effects. The problem is that a strict application of the standard requires that many of these functions in fact have side effects under error conditions, such as a negative argument passed to the sqrt function. - 31 - To force use of the square root operations for evaluating the functions sqrt and sqrtf, use the commandline option -D__INLINE_INTRINSICS. To improve performance of code using other functions in the standard math library use the option -D__MATH_HAS_NO_SIDE_EFFECTS. +o Exception runtime failures (Bug #405567). Runtime assertion errors will result if an exception is thrown as a result of reaching the per process file descriptor limit or if there is no more memory available. The default operator new does not throw an exception when allocation of requested storage fails. +o Making a static/extern _l_o_c_a_l in a mp region is not implemented (Bug #437716). Consider the following example: The variable _i declared as a _s_t_a_t_i_c _i_n_t is being made local in the parallel region. The semantics of _l_o_c_a_l dictate that a local copy is made within each process and the local copy is initialized to -3. However, the call to _f() within the parallel region also refers to _i which should still get the value assigned to the _s_t_a_t_i_c _i_n_t ( i.e. 44). This is indeed the observed behavior when _f() is not inlined. However, if _f() is inlined, the _i that it refers to gets a value of -3. To workaround this problem remove the local _i and replace it by _i_n_t _i in the parallel region. This has the same effect as declaring _i as a local, since by default, variables declared within an MP region are local. The code below illustrates this: - 32 - #include <stdio.h> static int i; __inline int f () { return i < 0;} void main() { i = 44; /* workaround: remove the "local i" replace by "int i" in the parallel region // This has the same effect as declaring i as a local since by default // variables declared within an MP region are local */ #pragma parallel local (i) { i = -3; if (f()) printf("Incorrect ANSWER wrt mp "); else printf("Correct Answer wrt mp"); } +o Under certain very rare circumstances, a compiler internal error results in the message "A goto outside a region cannot jump to a label inside a region." This error occurs only when exceptions are enabled, and is known to occur only when a natural if-then-else is written with if's and goto's: e.g. if (n == 0) goto label1; goto label2; label1: ... label2: ... If the source cannot be rewritten, then the program should be compiled with -LANG:exceptions=off. +o The use of -anach with -n32 is deprecated (Bug #514250) The following example (see the function proc_bad) illustrates a style of function definition (similar to the K&R mode in C) which was supported with the -anach flag in the ucode compilers for historical reasons. The C++ standard requires the user to write the function in a style consistent with the ANSI C style (see the function proc_good). With CC -32 -anach the code compiles and produces correct results (values of 123 and 123 get printed). With CC -n32 -anach the code does compile, however it produces incorrect results (a value of 123, and 0 get printed). - 33 - #include <stdio.h> class C { public: int v; C() { v = 123; }; C(C& ob) { v = ob.v; }; }; int proc_good(C c) { return c.v; } int proc_bad(c) C c; { return c.v; } // rewrite as proc_good main() { C c; printf("%d0, proc_good(c)); printf("%d0, proc_bad(c)); } We suggest that the function proc_bad be rewritten as proc_good to conform to the C++ standard. Such a source transformation can even be done using a script. +o Internal error with exceptions and IPA (Bug# 512292). Under rare circumstances (when exceptions are on and when compiling with -IPA and when certain other conditions apply) the compiler may generate an internal error. As a workaround we suggest with -IPA:clone=off, or if the code doesn't throw or catch or propogate exceptions, compiling with -LANG:exceptions=off. +o Generating assembly using -S can cause a coredump if extremely long names (such as those generated by C++ template functions) are involved. (Bug #707102). +o C/C++ internal error (Bug #480882). The C/C++ compilers reserve the charcaters 0x81 and 0x82. Usage of these characters might either cause the compiler to core dump or emit the following error: Internal error loop: nested_source_line_modif: bad address